In a typical data system, such as an enterprise data system, a various users operating client machines (i.e., clients) may be concurrently connected to one or more data system application servers to access data in one or more shared databases via corresponding data system “middleware” applications. These client connections may comprise a local area network (LAN) or wide area network (WAN) connection, or a Web-based connection, wherein a Web client may access the data system via the Internet. Generally, the various users of the data system are enabled to access (e.g., read, insert, update, and/or delete) data stored in the database(s) via the middleware applications in connection with appropriate client-side software. The net result is that data in the data system database(s) are constantly changing.
In many instances, the data in the database(s) will be used by more than one data system application. For example, a common set of data hosted by a data system may be used to support a Customer Relationship Management (CRM) application, a Sales application, an Employee Relationship Management (ERM) application, a Human Resources (HR) application, a billing application, etc. Generally, these applications may run in a middleware layer, or may run as an external third-party application that accesses the data in the data system via an application program interface (API) provided by the data system that is designed for such purposes. The effect of sharing a common set of data across applications is that changes made via one of the applications may affect data used by another application. Under this scenario, it may be desired to alert the other application(s) that the data has changed. In other instances in which only a single application provides access to the database (or a particular set of data hosted by the database), changes to the database may changes in which the use of similar alert would be advantageous.
Typically, such alert conditions may be handled at the database level or at the middleware level. For example, most databases used for large-scale data systems provide “trigger” mechanisms that enable predefined operations to be automatically performed in response to a triggering event, such as before insert, update and delete, and after insert, update, and delete triggers common to SQL-based RDBMS databases. Each trigger includes logic and operations defined by corresponding trigger code that are executed in response to the triggering event in a manner similar to executing code in a stored procedure. Typically, the trigger code will be used to automatically modify data in one or more other tables, perform an integrity check of the data being inserted (that can't be handled by the database's built-in integrity check mechanisms), and/or call one or more stored procedures to perform trigger-handling operations. In addition, in some database environments, the trigger and/or stored procedure may invoke a method used by software components external from the database software components, such as a middleware application. For example, some database servers allow triggers to invoke Java methods in middleware applications. In this way, the middleware application may be informed of the triggering event directly via the database trigger. In addition, alert conditions may be handled via the middleware application. Since some middleware applications provide an abstracted mechanism for accessing the database, developers of these applications can define triggering events and how they are handled through operations and logic defined by pre-written middleware software code.
Although there are mechanisms for informing middleware applications of triggering events, and defining and handling triggering events via middleware applications, there presently is no efficient mechanism for either enabling developers of external “third-party” applications to define triggering events at the database or middleware level without modifying the database or existing middleware software), or informing the external third-party applications of such triggering events. Since these are external applications are developed by third-party developers (i.e., developers who did not design the middleware data system application), they generally are not allowed direct access to the database schema, which is required to write database triggers, or to the middleware software code. Therefore, there is no way developers of the third-party applications can generate their own triggering events at the database layer or the middleware layer. As a result, in order to determine if various data system data have changed, the third-party application must use a “pull” mechanism, such as a data system query. This is very inefficient, as it causes significant overhead for both the third-party application and the data system.